本篇是菜鳥階段的最後一篇了，剛好也滿了半個月，等於是完成鐵人賽一半的賽程。
測試 (Testing) 這件事在軟體工程上一直都是一項重要的工作，而且它是在整個軟體開發流程 (SDLC) 的其中一環，而且市面上也有很多的專書 (但多半是英文書) 介紹它，只是依台灣目前的軟體產業生態，測試這件事一直沒有得到應有的重視，即便是具規模的軟體公司也未必擁有完備的軟體測試政策或流程，近年來台灣似乎已經有股重視測試的味道浮現，市面上軟體測試的書也愈來愈多了，這真的是個好現象。

軟體測試理論包含了軟體測試方法，軟體評核方法，軟體品管與追踨以及控制等議題，一篇文章基本上是講不完的，不過軟體測試方法可以分幾個大項：

1. 單元測試 (Unit Testing)
2. 整合測試 (Integrated Testing)
3. 系統測試 (System Testing)
4. 壓力測試 (Stress Testing)
5. 使用者接受度測試 (User Acceptance Testing) (通常是驗收時做的)

單元測試算是最貼近程式師的事了，因為寫單元測試碼的人正是程式師，每個單元測試的程式碼是依不同的測試目的所撰寫，以測試真正運行的程式碼的正確性，單元測試也是自動化測試 (Test Automation) 的核心，自動化測試只是驅動單元測試的程式碼，並回報測試結果，如果沒有單元測試碼的話，自動化測試工具仍舊是沒有用處的。所以習慣的養成才是測試有沒有辦法順利導入開發流程的關鍵，畢竟寫單元測試程式也是需要花時間的，如果因為寫太多單元測試程式而導致主要的程式進度 delay 也是不對的，因此讓這個習慣 "結凍" 是導入測試的團隊最重要的一件事。

整合測試是比單元測試高一級的測試，單元測試是依照單一程式碼區域 (ex: 類別，函式，屬性，事件等) 的反應進行測試，而整合測試是將兩個以上的類別做整合，並且測試它們之間的運作關係是不是正確的，例如一個訂單線上刷卡系統要同時更新訂單以及刷卡記錄，在本地資料庫中的訂單與刷卡記錄是否能成功完成更新，就需要靠整合測試來做 (將與銀行系統的連結先切開)，所以整合測試中的測試案例一定是跨類別物件的，通常是以會用到多個物件的用戶端來做 (單元測試則是該物件本身的用戶端)。

系統測試則除了整合測試外，再加上與其他系統的構連，以前例的線上刷卡系統為例，將銀行系統介接的測試加進來，就成為了系統測試，所以系統測試的涵蓋面很廣，而且多半要和其他系統的管理人員一起合作才能做，也是挺花時間的一種測試。壓力測試則是測驗系統在當下的軟硬體環境下能夠承受的壓力有多大，用來計算出系統的極限，以及如果要突破極限要怎麼做 (修改軟體程式或是增加硬體資源)。

最後的使用者接受度測試，則是使用者能否接受系統的一種測試，這種測試主觀面就很大，所以使用測試案例與 use case 鎖定測試的範圍，以及平時就要和使用者溝通甚至讓使用者參與介面設計是很重要的，否則這個測試可能會拖到天荒地老...

總之，菜鳥必須要認知，測試在整個軟體流程中是關鍵的工作，它也是掌控軟體品質的手段之一，而且可被自動化測試的程式，也可以在無形中給予程式師對這段程式的信心，提高這段程式重覆使用的品質，而它也是菜鳥階段必須養成的重要習慣，因為到了中鳥以上，可能想解凍就很因難了。